home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 12451 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.9 KB
  1. Path: nnrp.info.ucla.edu!jmartin
  2. From: jmartin@cs.ucla.edu (Jay Martin)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 20 Mar 1996 02:33:43 GMT
  6. Organization: University of California, Los Angeles
  7. Message-ID: <4inqq7$qli@saba.info.ucla.edu>
  8. References: <4idh80$6tj@solutions.solon.com> <4idk8oINNrr2@keats.ugrad.cs.ubc.ca> <4if97t$1cqm@saba.info.ucla.edu> <1996Mar19.183154.18826@amc.com>
  9. NNTP-Posting-Host: may.cs.ucla.edu
  10. X-Newsreader: NN version 6.5.0.b3.0 #9 (NOV)
  11.  
  12. sheldon@amc.com (Sheldon White) writes:
  13.  
  14. >In article <4if97t$1cqm@saba.info.ucla.edu> jmartin@cs.ucla.edu (Jay Martin) writes:
  15. >>c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
  16. >>
  17.  
  18. >(deletia)
  19.  
  20. >>
  21. >>Alright dumbshits lesson time:
  22. >>
  23. >>  -- Tools and operating systems that only support one language are junk.
  24. >>     Basic computer science, anyone who thinks otherwise is incompetent.
  25. >>  
  26.  
  27. >That's probably true. Fortunately, UNIX is not such a system.
  28.  
  29. Then where have been the standard system interfaces for all the
  30. other languages?  They don't exist.  UNIX only really supports
  31. one language, C.  Which is why C didn't die like all the other
  32. low level languages of its period.
  33.  
  34. >>  -- Stupidly go on and on about how an certain IO routine is not as fast
  35. >>     as Lex, not too swift.  (1) Won't matter if your reading in 1K.
  36. >>     (2) Just shows the IO routine is broken.  Its trivia.
  37. >>   
  38.  
  39. >I've worked on a lot of parsers, both using Yacc/Lex and using straight C
  40. >code. Unless the syntax was completely trivial, using a tool like Yacc is
  41. >vital for maintaining the code. Also, if your scanf version is too slow, what
  42. >are you going to do? Rewrite scanf()?
  43.  
  44. We were talking about a trivial table, something easily accomplished
  45. by standard IO routines in any language. That I mentioned "scanf" in a
  46. retort was not inportant (scanf == simple IO routines).  (Scanf is
  47. obsolete anyway use "iostream.h") If you are reading a 2K file at the
  48. start of a 2 day computation should you care?  If scanf is so slow its
  49. broken, like most of C.  Using Lex/Yacc to read in tables just for the
  50. sake of performance is really silly.  Its just another example of the
  51. rabid performance paranoia exhibited by C programmers.
  52.  
  53. >>  -- Go on and on how its great to over-engineer something simple.
  54. >>     How great it is to be a "savant" at a criptic tool with little
  55. >>     eye to the effects of using that tool to the maintainability
  56. >>     of the software.  This is called "eat shit next guy" hacking.
  57. >>
  58.  
  59. >Have you ever had to maintain a large parser, day in and day out, written in
  60. >"just-crank-some-code" C? Talk about "eat shit next guy"...
  61.  
  62. Yes I would and have used a parser tool like Yacc for a real parser
  63. (Though for a really good language compiler I hear its worth the pain
  64. of a recursive decent parser), but I wasn't talking about a parser
  65. or a real grammer we were talking about over engineering simple
  66. IO code.
  67.  
  68. >Have you ever used a tool like Yacc?
  69.  
  70. Yes
  71.  
  72. >>Of course when you tell of maintainance headaches caused by abuse of
  73. >>these tools do to they are ready availability and it is supposed to be
  74. >>so cool to use them.  Then its the usual C/Unix hacker macho attitude
  75. >>of "they are just lame programmers" the tools are great!  
  76. >>
  77.  
  78. >There's nothing cool about Yacc. There's nothing cool about a sledgehammer.
  79. >They are tools that can make life much, much easier.
  80.  
  81. If you are using them to do what they are supposed to do, then they
  82. are cool.  This whole thread is using complex tools when they are not
  83. necessary. One guy bragged about how cool it is to instead of just
  84. inputting a number, you allow arbitrarily complex expressions to be
  85. inputed. Extra complex tools causes maintance headaches because it
  86. requires expertise when it is not necessary. 
  87.  
  88. Suppose I have programmer that works for me "FORTRAN-Bob".  Bob
  89. doesn't have a CS degree and is learning C.
  90.  
  91. CS-Jay:  Well Bob your input file to your program should probably
  92.          be done as a parser.  Its really cool and allows you to
  93.          have "free format" input and stuff. 
  94.  
  95. FORTRAN-BOB:  You mean so it will be so easy to use as if it had a GUI or
  96.               DB front end?
  97.  
  98. CS-Jay: Well no not really, it will still suck, but I think parsers
  99.         are cool.  Well anyway you got to read some books, first
  100.         you will need to read this automata/language theory book
  101.         here, then half of this compilers text, after that you
  102.         should read thes lex and yacc books.  And so you don't
  103.         make any style mistakes read "Good style with Lex and
  104.         Yacc".
  105.  
  106. FORTRAN-BOB: (Thoughts) I wish I could use FORTRAN READ.
  107.  
  108. Moral: Just because you are an expert at something doesn't mean
  109. everyone else is.
  110.  
  111. >>The Unix philosophy is great for the quick hack, but for larger
  112. >>software development the philosophy becomes counter productive.
  113.  
  114. >I'm sorry, but you sound like someone who hasn't had to maintain a large
  115.  
  116. Yes I have maintained large programs.  The Unix philosophy is
  117. anti-software engineering (quick and dirty) if you ask me.
  118.  
  119. Jay
  120.